home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1120 < prev    next >
Text File  |  1995-07-25  |  26KB  |  619 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            V. Cerf
  8. Request for Comments:  1120                                          NRI
  9.                                                           September 1989
  10.  
  11.  
  12.                      The Internet Activities Board
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC provides a history and description of the Internet
  17.    Activities Board (IAB) and its subsidiary organizations.  This memo
  18.    is for informational use and does not constitute a standard.
  19.    Distribution of this memo is unlimited.
  20.  
  21. 1. Introduction
  22.  
  23.    In 1968, the U.S. Defense Advanced Research Projects Agency (DARPA)
  24.    initiated an effort to develop a technology which is now known as
  25.    packet switching.  This technology had its roots in message switching
  26.    methods, but was strongly influenced by the development of low-cost
  27.    minicomputers and digital telecommunications techniques during the
  28.    mid-1960's [BARAN 64, ROBERTS 70, HEART 70, ROBERTS 78].  A very
  29.    useful survey of this technology can be found in [IEEE 78].
  30.  
  31.    During the early 1970's, DARPA initiated a number of programs to
  32.    explore the use of packet switching methods in alternative media
  33.    including mobile radio, satellite and cable [IEEE 78, IEEE 87].
  34.    Concurrently, Xerox Palo Alto Research Center (PARC) began an
  35.    exploration of packet switching on coaxial cable which ultimately led
  36.    to the development of Ethernet local area networks [METCALFE 76].
  37.  
  38.    The successful implementation of packet radio and packet satellite
  39.    technology raised the question of interconnecting ARPANET with other
  40.    types of packet nets.  A possible solution to this problem was
  41.    proposed by Cerf and Kahn [CERF 74] in the form of an internetwork
  42.    protocol and a set of gateways to connect the different networks.
  43.    This solution was further developed as part of a research program in
  44.    internetting sponsored by DARPA and resulted in a collection of
  45.    computer communications protocols based on the original Transmission
  46.    Control Protocol (TCP) and its lower level counterpart, Internet
  47.    Protocol (IP).  Together, these protocols, along with many others
  48.    developed during the course of the research, are referred to as the
  49.    TCP/IP Protocol Suite [LEINER 85, POSTEL 85, CERF 82, CLARK 86, RFC
  50.    1100].
  51.  
  52.    In the early stages of the Internet research program, only a few
  53.    researchers worked to develop and test versions of the internet
  54.    protocols.  Over time, the size of this activity increased until, in
  55.  
  56.  
  57.  
  58. Cerf                                                            [Page 1]
  59.  
  60. RFC 1120                        The IAB                   September 1989
  61.  
  62.  
  63.    1979, it was necessary to form an informal committee to guide the
  64.    technical evolution of the protocol suite.  This group was called the
  65.    Internet Configuration Control Board (ICCB) and was established by
  66.    Dr. Vinton Cerf who was then the DARPA program manager for the
  67.    effort.  Dr. David C. Clark of the Lab for Computer Science at
  68.    Massachusetts Institute of Technology was named the chairman of this
  69.    committee.
  70.  
  71.    In January, 1983, the Defense Communications Agency, then responsible
  72.    for the operation of the ARPANET, declared the TCP/IP protocol suite
  73.    to be standard for the ARPANET and all systems on the network
  74.    converted from the earlier Network Control Program (NCP) to TCP/IP.
  75.    Late that year, the ICCB was reorganized by Dr. Barry Leiner, Cerf's
  76.    successor at DARPA, around a series of task forces considering
  77.    different technical aspects of internetting.  The re-organized group
  78.    was named the Internet Activities Board.
  79.  
  80.    As the Internet expanded, it drew support from U.S. Government
  81.    organizations including DARPA, the National Science Foundation (NSF),
  82.    the Department of Energy (DOE) and the National Aeronautics and Space
  83.    Administration (NASA).  Key managers in these organizations,
  84.    responsible for computer networking research and development, formed
  85.    an informal Federal Research Internet Coordinating Committee (FRICC)
  86.    to coordinate U.S. Government support for and development and use of
  87.    the Internet system.  The FRICC sponsors most of the U.S. research on
  88.    internetting, including support for the Internet Activities Board and
  89.    its subsidiary organizations.
  90.  
  91.    At the international level, a Coordinating Committee for
  92.    Intercontinental Research Networks (CCIRN) has been formed which
  93.    includes the U.S.  FRICC and its counterparts in North America and
  94.    Europe.  The CCIRN provides a forum for cooperative planning among
  95.    the principal North American and European research networking bodies.
  96.  
  97. 2. Internet Activities Board
  98.  
  99.    The Internet Activities Board (IAB) is the coordinating committee for
  100.    Internet design, engineering and management.  The Internet is a
  101.    collection of over a thousand packet switched networks located
  102.    principally in the U.S., but also includes systems in many other
  103.    parts of the world, all interlinked and operating using the protocols
  104.    of the TCP/IP protocol suite.  The IAB is an independent committee of
  105.    researchers and professionals with a technical interest in the health
  106.    and evolution of the Internet system.  Membership changes with time
  107.    to adjust to the current realities of the research interests of the
  108.    participants, the needs of the Internet system and the concerns of
  109.    the U.S. Government, university and industrial sponsors of the
  110.    elements of the Internet.
  111.  
  112.  
  113.  
  114. Cerf                                                            [Page 2]
  115.  
  116. RFC 1120                        The IAB                   September 1989
  117.  
  118.  
  119.    IAB members are deeply committed to making the Internet function
  120.    effectively and evolve to meet a large scale, high speed future.  All
  121.    IAB members are required to have at least one other major role in the
  122.    Internet community in addition to their IAB membership.  New members
  123.    are appointed by the chairman of the IAB, with the advice and consent
  124.    of the remaining members.  The chairman serves a term of two years.
  125.  
  126.    The IAB focuses on the TCP/IP protocol suite, and extensions to the
  127.    Internet system to support multiple protocol suites.
  128.  
  129.    The IAB has two principal subsidiary task forces:
  130.  
  131.       1) Internet Engineering Task Force (IETF)
  132.  
  133.       2) Internet Research Task Force (IRTF)
  134.  
  135.    Each of these Task Forces is led by a chairman and guided by a
  136.    Steering Group which reports to the IAB through its chairman.  Each
  137.    task force is organized by the chairman, as required, to carry out
  138.    its charter.  For the most part, a collection of Working Groups
  139.    carries out the work program of each Task Force.
  140.  
  141.    All decisions of the IAB are made public.  The principal vehicle by
  142.    which IAB decisions are propagated to the parties interested in the
  143.    Internet and its TCP/IP protocol suite is the Request for Comment
  144.    (RFC) note series.  The archival RFC series was initiated in 1969 by
  145.    Dr. Stephen D. Crocker as a means of documenting the development of
  146.    the original ARPANET protocol suite [RFC 1000].  The editor-in-chief
  147.    of this series, Dr. Jonathan B.  Postel, has maintained the quality
  148.    of and managed the archiving of this series since its inception.  A
  149.    small proportion of the RFCs document Internet standards.  Most of
  150.    them are intended to stimulate comment and discussion.  The small
  151.    number which document standards are especially marked in a "status"
  152.    section to indicate the special status of the document.  An RFC
  153.    summarizing the status of all standard RFCs is published regularly
  154.    [RFC 1100].
  155.  
  156.    RFCs describing experimental protocols, along with other submissions
  157.    whose intent is merely to inform, are typically submitted directly to
  158.    the RFC Editor.  A Standard RFC starts out as a Proposed Standard and
  159.    may be promoted to Draft Standard and finally Standard after suitable
  160.    review, comment, implementation, and testing.
  161.  
  162.    Prior to publication of a Proposed Standard, Draft Standard or
  163.    Standard RFC, it is made available for comment through an on-line
  164.    Internet-Draft directory.  Typically, these Internet-Drafts are
  165.    working documents of the IAB or of the working groups of the Internet
  166.    Engineering and Research Task Forces.  Internet Drafts are either
  167.  
  168.  
  169.  
  170. Cerf                                                            [Page 3]
  171.  
  172. RFC 1120                        The IAB                   September 1989
  173.  
  174.  
  175.    submitted to the RFC Editor for publication or discarded within three
  176.    months.
  177.  
  178.    The IAB performs the following functions:
  179.  
  180.       1)   Sets Internet Standards,
  181.  
  182.       2)   Manages the RFC publication process,
  183.  
  184.       3)   Reviews the operation of the IETF and IRTF,
  185.  
  186.       4)   Performs strategic planning for the Internet, identifying
  187.            long-range problems and opportunities,
  188.  
  189.       5)   Acts as a technical policy liaison and representative for the
  190.            Internet community, and
  191.  
  192.       6)   Resolves technical issues which cannot be treated within the
  193.            IETF or IRTF frameworks.
  194.  
  195.    To supplement its work via electronic mail, the IAB meets quarterly
  196.    to review the condition of the Internet, to review and approve
  197.    proposed changes or additions to the TCP/IP suite of protocols, to
  198.    set technical development priorities, to discuss policy matters which
  199.    may need the attention of the Internet sponsors, and to agree on the
  200.    addition or retirement of IAB members and on the addition or
  201.    retirement of task forces reporting to the IAB.  Typically, two of
  202.    the quarterly meetings are by means of video teleconferencing
  203.    (provided, when possible, through the experimental Internet packet
  204.    video-conferencing system).
  205.  
  206.    The IAB membership is currently as follows:
  207.  
  208.             Vinton Cerf          - Chairman
  209.             David Clark          - IRTF Chairman
  210.             Phillip Gross        - IETF Chairman
  211.             Jonathan Postel      - RFC Editor
  212.             Robert Braden        - Executive Director
  213.             Hans-Werner Braun    - Member
  214.             Barry Leiner         - Member
  215.             Daniel Lynch         - Member
  216.             Stephen Kent         - Member
  217.  
  218. 3.  The Internet Engineering Task Force
  219.  
  220.    The Internet has grown to encompass a large number of widely geo-
  221.    graphically dispersed networks in academic and research communities.
  222.    It now provides an infrastructure for a broad community with various
  223.  
  224.  
  225.  
  226. Cerf                                                            [Page 4]
  227.  
  228. RFC 1120                        The IAB                   September 1989
  229.  
  230.  
  231.    interests.  Moreover, the family of Internet protocols and system
  232.    components has moved from experimental to commercial development.  To
  233.    help coordinate the operation, management and evolution of the
  234.    Internet, the IAB established the Internet Engineering Task Force
  235.    (IETF).
  236.  
  237.    The IETF is chaired by Mr. Phillip Gross and managed by its Internet
  238.    Engineering Steering Group (IESG).  The IAB has delegated to the IESG
  239.    the general responsibility for making the Internet work and for the
  240.    resolution of all short- and mid-range protocol and architectural
  241.    issues required to make the Internet function effectively.
  242.  
  243.    The charter of the IETF includes:
  244.  
  245.       1) Responsibility for specifying the short and mid-term
  246.          Internet protocols and architecture and recommending
  247.          standards for IAB approval.
  248.  
  249.       2) Provision of a forum for the exchange of information within the
  250.          Internet community.
  251.  
  252.       3) Identification of pressing and relevant short- to mid-range
  253.          operational and technical problem areas and convening of
  254.          Working Groups to explore solutions.
  255.  
  256.    The Internet Engineering Task Force is a large open community of
  257.    network designers, operators, vendors, and researchers concerned with
  258.    the Internet and the Internet protocol suite.  It is organized around
  259.    a set of eight technical areas, each managed by a technical area
  260.    director.  In addition to the IETF Chairman, the area directors make
  261.    up the IESG membership.  Each area director has primary
  262.    responsibility for one area of Internet engineering activity, and
  263.    hence for a subset of the IETF Working Groups.  The area directors
  264.    have jobs of critical importance and difficulty and are selected not
  265.    only for their technical expertise but also for their managerial
  266.    skills and judgment.  At present, the eight technical areas and
  267.    chairs are:
  268.  
  269.             1) Applications          - TBD
  270.             2) Host Services         - Craig Partridge
  271.             3) Internet Services     - Noel Chiappa
  272.             4) Routing               - Robert Hinden
  273.             5) Network Management    - David Crocker
  274.             6) OSI Coexistence       - Ross Callon and Robert Hagens
  275.             7) Operations            - TBD
  276.             8) Security              - TBD
  277.  
  278.    The work of the IETF is performed by subcommittees known as Working
  279.  
  280.  
  281.  
  282. Cerf                                                            [Page 5]
  283.  
  284. RFC 1120                        The IAB                   September 1989
  285.  
  286.  
  287.    Groups.  There are currently more than 20 of these.  Working Groups
  288.    tend to have a narrow focus and a lifetime bounded by completion of a
  289.    specific task, although there are exceptions.  The IETF is a major
  290.    source of proposed protocol standards, for final approval by the IAB.
  291.  
  292.    The IETF meets quarterly and extensive minutes of the plenary
  293.    proceedings as well as reports from each of the working groups are
  294.    issued by the IAB Secretariat, at the Corporation for National
  295.    Research Initiatives.
  296.  
  297. 4.  The Internet Research Task Force
  298.  
  299.    To promote research in networking and the development of new
  300.    technology, the IAB established the Internet Research Task Force
  301.    (IRTF).
  302.  
  303.    In the area of network protocols, the distinction between research
  304.    and engineering is not always clear, so there will sometimes be
  305.    overlap between activities of the IETF and the IRTF.  There is, in
  306.    fact, considerable overlap in membership between the two groups. This
  307.    overlap is regarded as vital for cross-fertilization and technology
  308.    transfer.  In general, the distinction between research and
  309.    engineering is one of viewpoint and sometimes (but not always) time-
  310.    frame.  The IRTF is generally more concerned with understanding than
  311.    with products or standard protocols, although specific experimental
  312.    protocols may have to be developed, implemented and tested in order
  313.    to gain understanding.
  314.  
  315.    The IRTF is a community of network researchers, generally with an
  316.    Internet focus.  The work of the IRTF is governed by its Internet
  317.    Research Steering Group (IRSG).  The chairman of the IRTF and IRSG is
  318.    David Clark. The IRTF is organized into a number of Research Groups
  319.    (RGs) whose chairs are appointed by the chairman of the IRSG.  The RG
  320.    chairs and others selected by the IRSG chairman serve on the IRSG.
  321.  
  322.    These groups typically have 10 to 20 members, and each covers a broad
  323.    area of research, pursuing specific topics, determined at least in
  324.    part by the interests of the members and by recommendations of the
  325.    IAB.
  326.  
  327.    The current members of the IRSG are as follows:
  328.  
  329.             David Clark         - Chairman
  330.             Robert Braden       - End-to-End Services
  331.             Douglas Comer       - Member at Large
  332.             Deborah Estrin      - Autonomous Networks
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Cerf                                                            [Page 6]
  339.  
  340. RFC 1120                        The IAB                   September 1989
  341.  
  342.  
  343.             Stephen Kent        - Privacy and Security
  344.             Keith Lantz         - User Interfaces
  345.             David Mills         - Member at Large
  346.  
  347. 5. The Near-term Agenda of the IAB
  348.  
  349.    There are seven principal foci of IAB attention for the period 1989 -
  350.    1990:
  351.  
  352.       1) Operational Stability
  353.       2) User Services
  354.       3) OSI Coexistence
  355.       4) Testbed Facilities
  356.       5) Security
  357.       6) Getting Big
  358.       7) Getting Fast
  359.  
  360.    Operational stability of the Internet is a critical concern for all
  361.    of its users.  Better tools are needed for gathering operational
  362.    data, to assist in fault isolation at all levels and to analyze the
  363.    performance of the system.  Opportunities abound for increased
  364.    cooperation among the operators of the various Internet components
  365.    [RFC 1109].  Specific, known problems should be dealt with, such as
  366.    implementation deficiencies in some version of the BIND domain name
  367.    service resolver software.  To the extent that the existing Exterior
  368.    Gateway Protocol (EGP) is only able to support limited topologies,
  369.    constraints on topological linkages and allowed transit paths should
  370.    be enforced until a more general Inter-Autonomous System routing
  371.    protocol can be specified.  Flexibility for Internet implementation
  372.    would be enhanced by the adoption of a common internal gateway
  373.    routing protocol by all vendors of internet routers.  A major effort
  374.    is recommended to achieve conformance to the Host Requirements RFCs
  375.    which are to be published early in the fourth quarter of calendar
  376.    1989.
  377.  
  378.    Among the most needed user services, the White Pages (an electronic
  379.    mailbox directory service) seems the most pressing.  Efforts should
  380.    be focused on widespread deployment of these capabilities in the
  381.    Internet by mid-1990.  The IAB recommends that existing white pages
  382.    facilities and newer ones, such as X.500, be populated with up-to-
  383.    date user information and made accessible to Internet users and users
  384.    of other systems (e.g., commercial email carriers) linked to the
  385.    Internet.  Connectivity with commercial electronic mail carriers
  386.    should be vigorously pursued, as well as links to other network
  387.    research communities in Europe and the rest of the world.
  388.  
  389.    Development and deployment of privacy-enhanced electronic mail
  390.    software should be accelerated in 1990 after release of public domain
  391.  
  392.  
  393.  
  394. Cerf                                                            [Page 7]
  395.  
  396. RFC 1120                        The IAB                   September 1989
  397.  
  398.  
  399.    software implementing the private electronic mail standards [RFC
  400.    1113, RFC 1114, and RFC 1115].  Finally, support for new or enhanced
  401.    applications such as computer-based conferencing, multi-media
  402.    messaging and collaboration support systems should be developed.
  403.  
  404.    The National Network Testbed (NNT) resources planned by the FRICC
  405.    should be applied to support conferencing and collaboration protocol
  406.    development and application experiments and to support multi-vendor
  407.    router interoperability testing (e.g., interior and exterior routing,
  408.    network management, multi-protocol routing and forwarding).
  409.  
  410.    With respect to growth in the Internet, architectural attention
  411.    should be focused on scaling the system to hundreds of millions of
  412.    users and hundreds of thousands of networks.  The naming, addressing,
  413.    routing and navigation problems occasioned by such growth should be
  414.    analyzed.  Similarly, research should be carried out on analyzing the
  415.    limits to the existing Internet architecture, including the ability
  416.    of the present protocol suite to cope with speeds in the gigabit
  417.    range and latencies varying from microseconds to seconds in duration.
  418.  
  419.    The Internet should be positioned to support the use of OSI protocols
  420.    by the end of 1990 or sooner, if possible.  Provision for multi-
  421.    protocol routing and forwarding among diverse vendor routes is one
  422.    important goal.  Introduction of X.400 electronic mail services and
  423.    interoperation with RFC 822/SMTP [RFC 822, RFC 821, RFC 987, RFC
  424.    1026] should be targeted for 1990 as well.  These efforts will need
  425.    to work in conjunction with the White Pages services mentioned above.
  426.    The IETF, in particular, should establish liaison with various OSI
  427.    working groups (e.g., at NIST, RARE, Network Management Forum) to
  428.    coordinate planning for OSI introduction into the Internet and to
  429.    facilitate registration of information pertinent to the Internet with
  430.    the various authorities responsible for OSI standards in the United
  431.    States.
  432.  
  433. Security Considerations
  434.  
  435.    Finally, with respect to security, a concerted effort should be made
  436.    to develop guidance and documentation for Internet host managers
  437.    concerning configuration management, known security problems (and
  438.    their solutions) and software and technologies available to provide
  439.    enhanced security and privacy to the users of the Internet.
  440.  
  441. REFERENCES
  442.  
  443.        [BARAN 64]  Baran, P., et al, "On Distributed Communications",
  444.        Volumes I-XI, RAND Corporation Research Documents, August 1964.
  445.  
  446.        [CERF 74]  Cerf V., and R. Kahn, "A Protocol for Packet Network
  447.  
  448.  
  449.  
  450. Cerf                                                            [Page 8]
  451.  
  452. RFC 1120                        The IAB                   September 1989
  453.  
  454.  
  455.        Interconnection", IEEE Trans. on Communications, Vol. COM-22,
  456.        No. 5, pp. 637-648, May 1974.
  457.  
  458.        [CERF 82]  Cerf V., and E. Cain, "The DoD Internet Protocol
  459.        Architecture", Proceedings of the SHAPE Technology Center
  460.        Symposium on Interoperability of Automated Data Systems,
  461.        November 1982.  Also in Computer Networks and ISDN,
  462.        Vol. 17, No. 5, October 1983.
  463.  
  464.        [CLARK 86]  Clark, D., "The Design Philosophy of the DARPA
  465.        Internet protocols", Proceedings of the SIGCOMM '88 Symposium,
  466.        Computer Communications Review, Vol. 18, No. 4, pp. 106-114,
  467.        August 1988.
  468.  
  469.        [HEART 70]  Heart, F., R. Kahn, S. Ornstein, W. Crowther, and D.
  470.        Walden, "The Interface Message Processor for the ARPA Computer
  471.        Network", AFIPS Conf. Proc. 36, pp. 551-567, June 1970.
  472.  
  473.        [IEEE 78]  Kahn, R. (Guest Editor), K. Uncapher, and
  474.        H. Van Trees (Associate Guest Editors), Proceedings of the
  475.        IEEE, Special Issue on Packet Communication Networks,
  476.        Volume 66, No. 11, pp. 1303-1576, November 1978.
  477.  
  478.        [IEEE 87]  Leiner, B. (Guest Editor), D. Nielson, and
  479.        F. Tobagi (Associate Guest Editors), Proceedings of the
  480.        IEEE, Special Issue on Packet Radio Networks, Volume 75,
  481.        No. 1, pp. 1-272, January 1987.
  482.  
  483.        [LEINER 85]  Leiner, B., R. Cole, J.  Postel, and D. Mills,
  484.        "The DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C.,
  485.        March 1985.  Also in IEEE Communications Magazine, March 1985.
  486.  
  487.        [METCALFE 76]  Metcalfe, R., and D. Boggs, "Ethernet:
  488.        Distributed Packet for Local Computer Networks", Communications
  489.        of the ACM, Vol. 19, No. 7, pp. 395-404, July 1976.
  490.  
  491.        [POSTEL 85]  Postel, J., "Internetwork Applications Using the
  492.        DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C.,
  493.        March 1985.
  494.  
  495.        [RFC 821]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
  496.        USC/Information Sciences Institute, August 1982.
  497.  
  498.        [RFC 822]  Crocker, D., "Standard for the Format of ARPA Internet
  499.        Text Messages", RFC 822, University of Delaware, August 1982.
  500.  
  501.        [RFC 987]  Kille, S., "Mapping between X.400 and RFC 822",
  502.        University College London, June 1986.
  503.  
  504.  
  505.  
  506. Cerf                                                            [Page 9]
  507.  
  508. RFC 1120                        The IAB                   September 1989
  509.  
  510.  
  511.  
  512.        [RFC 1000]  Reynolds, J., and J. Postel, "The Request for
  513.        Comments References Guide", USC/Information Sciences Institute,
  514.        RFC 1000, August 1987.
  515.  
  516.        [RFC 1026]  Kille, S., "Addendum to RFC 987: (Mapping between
  517.        X.400 and RFC 822)", RFC 1026, University College London,
  518.        September 1987.
  519.  
  520.        [RFC 1100]  Postel, J. (Editor), "IAB Official Protocol
  521.        Standards", RFC 1100, April 1989.
  522.  
  523.        [RFC 1109]  Cerf, V., "Report of the Second Ad Hoc Network
  524.        Management Review Group", RFC 1109, NRI, August 1989.
  525.  
  526.        [RFC 1113]  Linn, J., "Privacy Enhancement for Internet
  527.        Electronic Mail: Part I -- Message Encipherment and
  528.        Authentication Procedures", RFC 1113, IAB Privacy Task
  529.        Force, August 1989.
  530.  
  531.        [RFC 1114]  Kent, S.,  and J. Linn, "Privacy Enhancement for
  532.        Internet Electronic Mail: Part II -- Certificate-based Key
  533.        Management", RFC 1114, IAB Privacy Task Force, August 1989.
  534.  
  535.        [RFC 1115]  Linn, J., "Privacy Enhancement for Internet
  536.        Electronic Mail: Part III -- Algorithms, Modes and Identifiers",
  537.        RFC 1115, IAB Privacy Task Force, August 1989.
  538.  
  539.        [ROBERTS 70]  Roberts, L., and B. Wessler, "Computer Network
  540.        Development to Achieve Resource Sharing", pp. 543-549,
  541.        Proc. SJCC 1970.
  542.  
  543.        [ROBERTS 78]  Roberts, L., "Evolution of Packet Switching",
  544.        Proc.  IEEE, Vol. 66, No. 11, pp. 1307-1313, November 1978.
  545.  
  546.        Note:  RFCs are available from the Network Information Center at
  547.        SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025,
  548.        (1-800-235-3155), or on-line via anonymous file transfer from
  549.        NIC.DDN.MIL.
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Cerf                                                           [Page 10]
  563.  
  564. RFC 1120                        The IAB                   September 1989
  565.  
  566.  
  567. Author's Address
  568.  
  569.        Vinton G. Cerf
  570.        Corporation for National Research Initiatives
  571.        1895 Preston White Drive, Suite 100
  572.        Reston, VA 22091
  573.  
  574.        Phone: (703) 620-8990
  575.  
  576.        EMail: VCERF@NRI.RESTON.VA.US
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Cerf                                                           [Page 11]
  619.